home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 281 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.5 KB  |  107 lines
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: David Byrden <100101.2547@compuserve.com>
  3. Newsgroups: comp.std.c++
  4. Subject: Can one do this in a handler???
  5. Date: 5 Feb 1996 00:09:29 GMT
  6. Organization: self-employed
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4f3hs1$si7@news.bridge.net>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Nntp-Posting-Host: ppp-mia3-107.bridge.net
  14. X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
  15. Content-Length: 2822
  16. Originator: clamage@taumet
  17.  
  18.  
  19.  
  20. I am studying the problem of writing exception-safe code,and have 
  21. designed a small class which illustrates a technique of holding 
  22. exceptions in abeyance while you continue to do some cleanup work. 
  23.  
  24. I wonder if anyone would examine the destructor of this class and tell 
  25. me whether they can see it violating the C++ standard; I have of course 
  26. examined that myself, but find it somewhat ambigous on the subject of 
  27. exceptions caught by the ellipsis.
  28.  
  29.  
  30. This template class owns a block of heap memory. The memory is allocated 
  31. as an array of char; later, the placement "new" is used to construct T 
  32. objects in the memory block. The Ts are all placed contigously from the 
  33. start of the block, and the number of Ts in the block is remembered by a 
  34. data member in the class.
  35.  
  36.  
  37. template< class T>
  38. class Tblock
  39. {
  40.    T* theBlock ;     // Start of the memory block
  41.    int count  ;      // Number of T objects in it
  42.    Tblock() ;
  43.    ~Tblock() ;
  44. } ;
  45.  
  46.  
  47. The interesting part is the Tblock destructor. The destructor of class T 
  48. is assumed to be able to throw exceptions, and I attempt to correctly 
  49. destroy the Tblock object even when that happens.
  50.  
  51.  
  52. template< class T >
  53. Tblock<T>::~Tblock( )
  54. {
  55.    try
  56.    {
  57.       for(  count-- ; count >= 0 ; count-- )
  58.          theBlock[count].~T() ;      // [a]
  59.       delete [ ] static_cast<char*> theBlock ;
  60.    }
  61.    catch( ... )
  62.    {
  63.       ~Tblock( ) ;            // [b]
  64.       throw ;
  65.    }
  66. }
  67.  
  68.  
  69.  
  70. Notes:
  71.  
  72. 1  [a] and [b] are explicit destructor calls. I assume that this syntax 
  73.    is correct because of the example of an explicit destructor call in 
  74.    CopyConstructible Requirements  20.1.3.1
  75. 2  The intention is that the destructor shall explicitly destroy each T 
  76.    object with an explicit destructor call, working down from the 
  77.    highest-numbered T in the block to zero.
  78. 3  Any T may throw any exception from its destructor. In that case, we 
  79.    go to the catch block and catch it with the intention of rethrowing 
  80.    it later. 
  81. 4  The catch handler in the destructor explicitly calls the destructor 
  82.    itself. The intended  effect of this is that the counter shall
  83.    continue downwards, destroying the remaining T objects, while the 
  84.    exception from the bad one remains in abeyance, waiting to be 
  85.    rethrown.
  86. 5  The destructor call is recursive. Any and all of the T objects may 
  87.    throw from its destructor, and yet the "good" ones will all be 
  88.    destroyed,and finally the memory will be deleted. If exceptions 
  89.    are thrown by any T objects, the most recently thrown one will 
  90.    propagate out of the Tblock dtor.
  91. 6  Incidentally, it is illegal to remove the outermost brackets and make 
  92.    the whole thing a function-try-block, because calling the destructor 
  93.    from the handler would result in undefined behaviour.
  94.  
  95.  
  96.           Thankyou
  97.  
  98.  
  99.                              David
  100.  
  101.  
  102.  
  103. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  104.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  105.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  106. ]
  107.